Communication networks are deployed worldwide to carry a variety of digital and analog information such as voice, video, and data between networked devices. Multi-hop and data forwarding, interconnection of networks and sub-networks, and other capabilities enable wide-ranging communication services to be provided to devices communicating over a variety of wired (electrical or optical) and/or wireless networks, for example.
Due to practical considerations, network communication is often limited in one or more ways. For example, servers and store-and-forward networked devices such as routers can only handle communications at a limited rate. When a large number of devices attempt to concurrently communicate with or through such a device, quality of the communications may therefore degrade.
As another example, network or sub-network boundaries may need to be traversed to facilitate a desired communication path. Such boundaries may exist at the interface between technologically disparate portions of a network, for example between a wired and wireless network, or between different types of wired and/or wireless networks. Boundaries may also exist for security or network administration purposes. For example, a network may be protected or regulated by a firewall, or a network address translation (NAT) device may exist at a network boundary.
An example network scenario, potentially illustrating such limitations, is depicted in FIG. 1. Mobile devices 110a-110f, such as wireless phones, PDAs, and laptop computers associated with a first sub-network 120 such as a mobile network operator's (MNO) network may require periodic communication, across a sub-network boundary 130, with devices such as internet protocol (IP) based devices residing outside the first sub-network 120, for example a server 140. The sub-network boundary 130 may include a firewall or network address translator (NAT), for example. The server 140 may be accessible through an external network or sub-network 135, and mobile devices 110a-110f, may each independently communicate with one or more servers 140 to obtain content pertaining to email, device management, news updates, multimedia messages, or other information.
In some instances, mobile devices such as illustrated in FIG. 1 may not have a publicly routable IP address, for example when they are part of a private address space behind the MNO's firewall and/or NAT, wherein in FIG. 1, the NAT can be positioned above the sub-network boundary 130. Applications running on such mobile devices may therefore be designed in such a way that data transactions are initiated by the mobile device to connect to a server which does have a publicly routable IP address. Thus, the server can respond to a mobile device once a transaction is initiated, but cannot initiate a transaction on its own.
However, there are also cases where the ability for the server to initiate a transaction with the mobile device is desired, for example when a device management server wishes to query the mobile devices to retrieve various diagnostics. Server-initiated transactions may be problematic since they may be prevented by the configuration of devices at the network boundary. For example a NAT may block incoming IP-based communications from the server to a mobile device, either due to configuration or technological limitations such as an inability for the NAT to retain an open port indefinitely for access to every mobile device.
To address this and other problems, the Open Mobile Alliance (OMA) has standardized the Wireless Application Protocol (WAP), including the use of WAP Push. This is a mechanism of waking up a mobile device via Short Message Service (SMS) to prompt it to initiate a session with the server. However, there are cases where SMS is not available or is deemed too expensive either in cost or in latency to be viable for a large number of mobile devices. WAP Push also requires the server to have the security access or authorization to send SMS messages to the mobile device network.
As another approach, applications running on mobile devices, such as email, instant messaging, games, etc. can be configured to circumvent the problem of blocked server-initiated communications. In such applications, mobile devices periodically poll a server to determine if the server has any messages pending for it. The server can typically respond through the NAT or firewall since such mobile device-initiated communication typically opens a temporary return communication path from the server to the mobile device. However, polling solutions necessarily involve a certain amount of latency in delivery of messages to the client, for example the mobile device.
However, there are applications, such as those pertaining to mobile device management, where the server needs to have a short and sometimes predictable amount of latency in getting a message to the mobile device. In general, there is a trade-off between latency and the consumption of system resources. For example, a mobile device which polls very often will reduce the latency, but at the expense of an undesirably reduced battery life. In addition, if multiple mobile devices frequently conduct polling, undesirably heavy demand is placed on both the servers being polled and the devices along the network boundary. For example, such demands over a given time interval can be viewed as roughly proportional to the product of the number of mobile devices and their average polling frequency. Heavy demand can reduce quality of service and work against the desire to reduce latency. That is, such methods are not scalable.
In a related approach, client polling, as described above, is performed often enough to maintain an open return path through the network boundary or NAT, so that the server can send messages back to the mobile device asynchronously as long as the return path remains open. This may require the mobile device, the server, or both to periodically send keep-alive messages to prevent the mapping in the NAT from timing out. This approach still relies on client polling at a minimum frequency, but reduces latency of messages sent to the mobile device since the server can initiate communication through the return path maintained through polling. However, mobile devices are still required to expend a significant amount of energy, and use a significant amount of network resources, to maintain the open return path. Moreover, if several mobile devices perform this approach, the NAT and server may become overwhelmed with polling requests.
More generally, maintaining multiple open communication paths in a point-to-multipoint network, such as a network comprising a server serving multiple clients or mobile devices, may require a degree of network overhead which significantly stresses portions of the network if performed according to the above prior art methods. For example, polling or keep-alive messages may stress servers, routers, firewalls, NATs, and/or clients within the network. As network size increases, requirements such as low latency become increasingly difficult to satisfy due to the need to directly maintain multiple network paths in such a network using traditional approaches.
Therefore there is a need for a method and system for communicating between a first set of networked devices and a second networked device that is not subject to one or more limitations in the prior art.
This background information is provided for the purpose of making known information believed by the applicant to be of possible relevance to the present invention. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present invention.